Machine control, up to the present, was in general dependent on so-called ladder diagrams which were manually constructed either from the requirements for the machine or from a flow chart which was manually translated into a ladder diagram. The ladder diagram technique has been utilized, inter alia, to specify control systems involving relays and solenoids, motors, valves, hydraulic systems, lights, switches, and other electro-mechanical devices for drilling, welding, paint spraying, assembling parts, materials handling, fabrication, and in general control of machines for whatever purpose. However, ladder diagrams are extremely cumbersome in usage, and while there has been a large amount of experience with such ladder diagrams, they do not emulate the normal though process as well as do flow charts.
Flow charts, in general, include Decision blocks and other types of blocks, called Action blocks, which track closely the mental processes required to instruct a machine to go through various procedures. Regardless of the ability to describe machine function in flow chart form in the past, machines were treated as fixtures controllable by switches, solenoids, timers, etc., which were representable in ladder diagram form. The fixture might be a riveting machine or the fixture could be a drill and riveting machine. As manufacturing processes became more complex so did the language necessary for machine control, with the ladder diagram technique being almost impossible to implement, especially for closed loop systems.
In order to implement a ladder diagram, a specialized controller, such as manufactured by Gould or Allen Bradley, was built which was programmed in ladder language so that once a change was made in operation of the machine which the controller was to control, the controller had to be reprogrammed at the ladder language level in order to make the change. Such a change could merely involve the altering of a the stop point in the movement of an arm, head, or other mechanical device.
In summary, prior to the Subject Invention there existed so-called programmable controllers which operated in a harsh industrial environment and sensed inputs and outputs, and controlled machines with ladder language developed from traditional relay diagrams, which were difficult to construct, much less alter.
In the middle 1980's, Universal Automation of Hudson, N.H. developed a methodology and system for programming machines, especially robots, by defining the operation of a simple robot or machine through the use of a number of pictorially designated decision, logic, data entry, or run-time blocks as exemplified by CONTROL, WAIT, MOVE, EXIT, DECISION, and COMPARE flow chart blocks.
In these earlier machines a flow chart was manually generated using these flow chart blocks and each flow chart block could be called up at a computer console, at which time all of the particular tasks to be performed by that block were entered in tabular form, from whence the programmer went to the next sequential block. The reason for the use of flow charts as opposed to ladder diagrams was that flow charts could be drawn to represent almost any type of task involved, and more closely emulated the human thought process. Thus, any task could be represented in flow chart form and, with the ability to automatically execute a flow chart, the early Universal Automation system provided a powerful tool in which levels upon levels of programming could be eliminated.
Moreover, for the early Universal Automation systems, rather than scanning through the entire computer memory, tasks were performed on a block-by-block basis, in which the machines were controlled by virtue of the compiling of the final flow chart or flow charts into data converted through an Executive program into run-time instructions for each of the individual machines. In that sense, the computer-generated flow charts actually controlled the end use devices.
One of the features of the earlier work done by Universal Automation was the fact that, rather than time multiplexing tasks to be done without regard to the length of the task that had to be done, each individual flow chart block was executed, with the execution taking only that length of time necessary for the execution of a particular block. The execution of the blocks continued as long as the next block number was higher than the previous block number, with the task being suspended when the block number was equal to or lower than that of the block being executed. This minimized the amount of time necessary for the utilization of memory and computer power, such that personal computers were able to handle not only the generation of a flow chart but also the execution of a flow chart without the use of time multiplexing or conversion to another programming language.
As will be appreciated, the earlier work by Universal Automation completely bypassed the programmable controller by providing an image of the flow chart, created block-by-block, in the virtual memory of a computer. Thus the earlier Universal Automation systems completely bypassed the ladder diagrams in favor of executing a compiled flow chart or flow charts, which eliminated the need for the programmable controller and added an area of generality which was user-friendly to the point that a flow chart could be manually generated and then entered block-by-block into the computer. It will be appreciated that in these earlier systems the flow chart was drawn on a piece of paper and entered into the computer on a series of prompts. There was no display of a flow chart symbol on the screen. The computer served merely as an interface which asked questions about the drawn flow chart, which answers were entered into the computer so that the program could run.
Later Universal Automation introduced a system which displayed a single block of a flow chart so that entries could be made in a menu to the side of this single block. The block took one of six forms, e.g. one of those mentioned above, with each of the blocks being numbered. This permitted, in a limited way, the verification of inputting correct information.
The six types of blocks were as follows: The first type of block was a CONTROL block that allowed the user to turn on or off an output signal from the personal computer or CPU. It also allowed a turn on or off of an internal flag bit, a start, a stop, or a reset of a timer, or a clear, increment or decrement of an internal counter. Thus, the purpose of the CONTROL block was for instance, to start timers, increment counters, decrement counters, and then provide control that the turning on or off of an output signal would provide. The second block was a WAIT block which established a predetermined delay in the flow chart. WAIT blocks were obviously important to allow other things to occur, and the amount of delay was settable. The third block was a MOVE block which moved data through the system in parallel. In other words, the MOVE block permitted groups of input data or the value of counters or registers to be moved to output nodes, or to counters or registers. The next type of block was an EXIT block which allowed the user to leave the flow chart to go to any other type language required. The fifth type of block was the DECISION block which allowed the user to base a yes or no decision on an input sensor. It could also base a decision on internal bits being true, certain function keys on the computer keyboard being pressed, or certain time-out timers being completed. The sixth block was a COMPARE block which permitted the comparison of values in which a yes/no decision could be based on a result equal to or greater than or less than the particular values to be compared.
It will be noted that the blocks in the prior Universal Automation machines could be accessed individually by block numbers, but this required the user to have a separate handwritten flow chart in order to be able to ascertain what block to access prior to going to the computer screen to either alter, change, delete, or modify the function of a single block.
Once all the blocks had been completed in a hand-done flow chart and entered into the computer, each block was displayed one at a time and verified by the operator. Assuming that the program met the specifications of the programmer, the information was compiled into data which, upon operation of an Executive program, drove I/O devices to execute the particular flow chart through the transmission of signals to the end-use machine.
The first flow chart programmers included a so-called editor, in which the flow charts were entered, with the editor displaying one block of the flow chart at a time, and with a menu of value selections to one side or the other of a block. These earlier machines also included a compiler, which compiled the flow chart or flow charts and created object data for use by the Executive program. The compiler also checked the flow chart for correctness of connection points, with the compiler producing a data file which was dependent on the types of blocks used, the connection points within the flow charts and various other criteria. Thus, in these machines, once compiled, data from the compiler was acted on by the Executive program to execute the flow chart by generating proper signals to I/O devices.
It will be noted that in the earlier Universal Automation machines, the compiler did not have to change from computer to computer or application to application. The Executive program was virtually all that was necessary to change and it could be changed in one or two ways. It was changed dependent upon the particular I/O system and also was changed for the given microprocessor utilized. Thus, until the particular microprocessor or input/output device was specified, there was no need to change the Executive portion of the program. The Edit programs and Compiler programs were completely independent and, from that basis alone, provided an editing advantage in that all editing and program generation was done in flow chart format.
Moreover, the earlier Universal Automation systems proved to run two to five times faster than the programmable controllers. This was because when a programmable computer solves its logic, it has to scan all of its memory locations to determine what to do. With the flow chart method of programming and execution, as will be discussed, one keeps track of where one is on each flow chart all the time. The Universal Automation system in effect only executes those statements of blocks on the flow chart that have to do with any particular given scan. Thus, the scan rate of the Universal Automation system was from two to five times faster than programmable controller scan rates.
One of the basic difficulties involved in the early Universal Automation systems was that no continuous flow chart, or part thereof, was produced on the computer screen. This became very inconvenient with respect to the formulation and generation of flow charts. A not small number of error routinely occurred in transferring a hand-drawn flow chart block-by-block to the single block representation of the flow chart on the screen. Also, one of the problems in representation of even a single flow chart block on the screen was the size of the screen and the inability to produce characters which were small enough to fit beside the representation of the block. Thus, menus were used on one side of the flow chart block to describe what was going on in the flow chart block. Moreover, this involved mental correspondence of a block to a chart of data. Another problem with the earlier machines was that the flow chart block was not drawn on the machine. Rather it was printed out on a printer which increased the difficulty in entering in the flow charts.
By way of further background, another and very real problem confronting the industry was the ability to reprogram the machines or robots "on the spot" when, for instance, a particular program did not provide expected machine movement or a machine broke down. It was ordinarily necessary, even with the early Universal Automation systems, to go back to the original program which was done by hand, correct it, re-enter it, and then recompile the program and run it to see if it would, in fact, run as expected. There was no ability to both interrupt the running of the program and to debug the program other than by guessing where in the program the error occurred. There was however a "freeze" capability in these early systems, as well as a rerun capability.
In summary, the earlier ladder diagram systems were almost intolerably complicated both in terms of the language involved and the debugging, as well as defining or redefining the role that the programmable controller was to play. While the early Universal Automation flow chart systems were easier to program than the ladder diagram systems, were faster than the programmable controllers, and alleviated the need for programmable controllers there was still a need for better programming and debugging techniques.